我们总结了弹性伸缩的五个条件与六个教训
前言
Cloud Native
弹性伸缩是云计算时代给我们带来的一项核心技术红利,但是 IT 的世界中,没有一个系统功能可以不假思索的应用到所有的场景中。这篇文章,我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时,在弹性场景下遇到的点滴做了一个系统的梳理,总结为五个条件和六个教训分享给大家。
五个条件
Cloud Native
1、启动无需手动干预
2、进程本身无状态
3、启动的要快,走的要有“尊严”
4、磁盘数据可丢失
5、依赖的服务充分可用
六个教训
Cloud Native
1、指标值设置不合理
弹性整体分为三个阶段:指标获取、规则计算、执行伸缩;指标获取一般通过监控系统或者 PaaS 平台自带的组件获取。基础监控指标常见的如:CPU/Mem/Load 等。短期内有一些基础指标数值会存在不稳定的特点,但是时间拉长,正常来看会处在一个“平稳”的状态,我们设置指标的时候,不能以短时间的特征为依据,参考较长时间的某种水位数据才能设置一个合理值。且指标不宜过多,同时缩容指标要和扩容指标存在明显的数值差。
2、把“延时”当指标
很多时候我们识别系统可用性的一个很大的判断,就是看系统屏幕是不是在“转圈圈”,即系统很慢。常理推断,很慢就要扩容了。所以我们有一些客户直接把系统的平均 RT 当成了扩容指标,但系统的 RT 是多维度的,比如 health check 一般都是很快的,这类 API 出现的频率稍高一点,一下就拉低了平均值。也有的客户会精确到 API 级别,可是 API 也是根据参数不同逻辑不一样的从而造成 RT 不一样。总之,根据延时去做弹性策略是很危险的一种做法。
3、指定单一的扩容规格
扩容规格指的是资源的规格,比如在云上的场景中,对于同一种 4c8g 的规格,我们可以指定内存型、计算型、网络增强型等。但是云上是一个大资源池,对于某一种规格,会存在售罄现象;如果我们只指定了单一的规格,就会出现资源无法提供而出现扩容失败的情况。这里最危险的还不是扩容失败本身,是出现业务故障之后的排查过程会特别漫长。
4、只考虑RPC链路中的应用策略
针对单个应用往往都很简单的,难的是整个业务场景的梳理。梳理思路一个简单的办法就是按照应用调用的场景进行,从应用间调用的场景来看,一般来说分为三种:同步(RPC,中间件如 Spring Cloud)、异步(消息,中间件如 RocketMQ)、任务(分布式调度,中间件如 SchedulerX)。我们一般会很快整理出第一种情况,但是很容易忽略掉后面两种。而后面两种出现问题的时候,问题排查诊断又是最为耗时。
5、没有配套相应的可视化策略
弹性伸缩是一个典型的后台任务,在治理一个大集群的后台任务的时候,最好是有一块大屏进行直观的可视化治理。对于扩容失败的情形,不能静默处理。如果是核心业务出现扩容失败,可能带来的就是直接的业务故障,但是故障真正发生时,很多时候不会去关心扩容策略是否生效,如果真是因为扩容造成的故障,也很难排查到这个点。
6、事前没做正确评估
虽然云计算给弹性提供了近乎无尽的资源池,但这也只是解放了用户预备资源的工作,而微服务系统本身复杂,单一组件的容量变化会产生全链路的影响,既解除一处风险之后系统瓶颈点可能会迁移,有些隐形约束也会随着容量变化逐步显现,所以做弹性策略大多数时候不能靠力大砖飞的思想,需要做好全链路的压测、验证,演练到适应于全局的弹性配置;我们还是建议事前从高可用的多个维度了解各种技术手段,形成多套预案以备使用。
尾声
Cloud Native